-
Notifications
You must be signed in to change notification settings - Fork 191
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
chore: tidy use of bpfSupportedMetrics for NewStats() #1629
chore: tidy use of bpfSupportedMetrics for NewStats() #1629
Conversation
🤖 SeineSailor Here is a concise summary of the pull request changes: Summary: The "chore: tidy universal use of bpfSupportedMetrics" pull request aims to standardize the use of Key Modifications:
Observations and Suggestions:
Overall, this pull request takes a step towards improving code consistency and maintainability. However, it requires further attention to ensure the changes do not impact the code's behavior. |
94c4ceb
to
4716a13
Compare
Hola @dave-tucker @sthaha @rootfs Would really appreciate a review if you get the chance. Thanks in advance |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Following up from my earlier comment I feel like we're treating a symptom (bpfSupportedMetrics is being passed everywhere) and not the disease (why does bpfSupportMetrics NEED to be plumbed in so many places).
The bigger problem is that pkg/stats
depending on pkg/bpf
...
However, pkg/stats
is regularly being called from parts of the codebase where a bpfExporter object isn't in scope.
I think the pkg/stats
-> pkg/bpf
dependency can be removed entirely by simply populating the hashmap with all the possible eBPF features. We're already filtering them before being posted to prometheus - see: CollectResUtilizationMetrics
. That should clean up most of the mess.
I don't feel like the cleanup to make pkg/model
depend on a maybe-unititialized value in pkg/stats
is a good idea - depending on being provided a bpfSupportedStats
struct seems fine.
4716a13
to
6079d67
Compare
6079d67
to
862315a
Compare
d2e2cc2
to
6d72d65
Compare
I've moved the stats globals cleanup to #1659 ... and i think this ready for another round of review |
6d72d65
to
8c2565e
Compare
@maryamtahhan can you rebase to pick the e2e test diagnostics? thanks |
8c2565e
to
1fda657
Compare
1fda657
to
f77516b
Compare
7e46b15
to
b11f1f7
Compare
Hi @dave-tucker Thanks in advance |
4510ec0
to
718d171
Compare
718d171
to
ce31e90
Compare
I will rebase this again |
698b1f8
to
1c223d2
Compare
This is rebase now :) \o/ yay! |
1c223d2
to
f95df6d
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM pending resolution of merge conflict
f95df6d
to
7ea948d
Compare
Remove the need to pass bpfSupportedMetrics through n layers of function calls that lead to NewStats() by adding a reasonable default set of bpfmetrics that the exporter will/can then override when it's started. Signed-off-by: Maryam Tahhan <[email protected]>
Tidy up the universal passing around of bpfSupportedMetrics for NewStats()
InitAvailableParamAndMetrics()
function and simply initialise the variables in the package at declaration.